Even though standards-based application software (e.g., Java™ based application software) has the potential to offer true competition at the software supplier level, legacy proprietary software has proven reliability, functionality and integration into customer information systems (IS) infrastructures. Customers are therefore placing operational dependency on standards-based software technologies with caution. Not surprisingly, present day application software servers tend to include instances of both standard and proprietary software suites, and, often, “problems” emerge in the operation of the newer standards-based software, or interoperation and integration of the same with legacy software applications.
The prior art application server 100 depicted in FIG. 1 provides a good example. FIG. 1 shows a prior art application server 100 having both an Advanced Business Application Programming™ (ABAP) legacy/proprietary software suite 103 and a Java 2 Enterprise Edition™ (J2EE) standards-based software suite 104. A connection manager 102 routes requests (e.g., HyperText Transfer Protocol (HTTP) requests and HTTP with secure socket layer (HTTPS) requests) associated with “sessions” between server 100 and numerous clients (not shown in FIG. 1) conducted over a network 101. A “session” can be viewed as the back and forth communication over a network 101 between computing systems (e.g., a particular client and the server).
The back and forth communication typically involves a client (“client”) sending a server 100 (“server”) a “request” that the server 100 interprets into some action to be performed by the server 100. The server 100 then performs the action and if appropriate returns a “response” to the client (e.g., a result of the action). Often, a session will involve multiple, perhaps many, requests and responses. A single session through its multiple requests may invoke different application software programs.
For each client request that is received by the application server's connection manager 102, the connection manager 102 decides to which software suite 103, 104 the request is to be forwarded. If the request is to be forwarded to the proprietary software suite 103, notification of the request is sent to a proprietary dispatcher 105, and, the request itself is forwarded into a request/response shared memory 106. The proprietary dispatcher 105 acts as a load balancer that decides which one of multiple proprietary worker nodes 1071 through 107L are to actually handle the request.
A worker node is a focal point for the performance of work. In the context of an application server that responds to client-server session requests, a worker node is a focal point for executing application software and/or issuing application software code for downloading to the client. The term “working process” generally means an operating system (OS) process that is used for the performance of work and is also understood to be a type of worker node. For convenience, the term “worker node” is used throughout the present discussion.
When the dispatcher 105 identifies a particular proprietary worker node for handling the aforementioned request, the request is transferred from the request/response shared memory 106 to the identified worker node. The identified worker node processes the request and writes the response to the request into the request/response shared memory 106. The response is then transferred from the request/response shared memory 106 to the connection manager 102. The connection manager 102 sends the response to the client via network 101.
Note that the request/response shared memory 106 is a memory resource that each of worker nodes 1071 through 107L has access to (as such, it is a “shared” memory resource). For any request written into the request/response shared memory 106 by the connection manager 102, the same request can be retrieved by any of worker nodes 1071 through 107L. Likewise, any of worker nodes 1071 through 107L can write a response into the request/response shared memory 106 that can later be retrieved by the connection manager 102. Thus the request/response shared memory 106 provides for the efficient transfer of request/response data between the connection manager 102 and the multiple proprietary worker nodes 1071 through 107L.
If the request is to be forwarded to the standards-based software suite 104, notification of the request is sent to the dispatcher 108 that is associated with the standards-based software suite 104. As observed in FIG. 1, the standards-based software suite 104 is a Java based software suite (in particular, a J2EE suite) that includes multiple worker nodes 1091 through 109N.
A Java Virtual Machine is associated with each worker node for executing the worker node's abstract application software code. For each request, dispatcher 108 decides which one of the N worker nodes is best able to handle the request (e.g., through a load balancing algorithm). Because no shared memory structure exists within the standards-based software suite 104 for transferring client session information between the connection manager 102 and the worker nodes 1091 through 109N, separate internal connections have to be established to send both notification of the request and the request itself to the dispatcher 108 from connection manager 102 for each worker node. The dispatcher 108 then forwards each request to its proper worker node.
Various problems exist with respect to the prior art application server 100 of FIG. 1. For example, the establishment of connections between the connection manager and the J2EE dispatcher to process a client session adds overhead/inefficiency within the standards-based software suite 104. For example, establishing connections between the connection manager and the J2EE dispatcher typically include copying data to and from the network stack. In addition, the J2EE dispatcher opens a separate select thread for each connection. Opening a number of separate threads can add overhead to the system because each thread uses resources such as memory. This increased overhead reduces the efficiency and scalability of application server 100.